Tagless

“Tagless” is an IoT project which uses Texas Instruments’s CC2650-LAUNCHXL board as a tag reader and android smartphones as physical tags.

Motivation

The main idea of the project is to let us in the modern IoT world to get rid of the clumsy and easily forgotten tags and start using our smartphones as tags instead. The advantages of using smartphones as tags are clear: We almost never forget our smartphones (and even if we do, we notice it very fast) and we are carrying them anyway (so no extra stuff is needed).

The tag reader board should be placed at the entrance of the company hall. Each employee installs the “Tagless App” android application and logs in with his very own unique id (PIN code – 4 digits which is given by the company). The employee shall report on arrivals and exits using the buttons “ENTER” and “EXIT” in the android application near the tag reader board.

Project structure

The project is composed of three main components:

  1. Board application:

    An extension of the project zero example (Simple Academy example project). The application is a BLE based application which allows us to transfer data using BLE protocol. In the case the transferred data is the employee’s working hours. The application stores all records in the external flash memory chip on the board in a cyclic data structure (which never loses work time) and permits admin users to dump the saved data (and with this action to clean the memory). The application supports around 100 employees and more than 800 records (enter or exit) each one.

  2. Android application:

    An extension of the BluetoothLeGatt application. The application scans for BLE advertisements, in addition to parsing and using the BLE services the advertiser offers. The application is consists of two screens, log-in screen and actions screen. In the log-in screen the employee should enter his own PIN code, in the actions screen the employee should report on enter/exit with the appointed buttons. If the employee is an elevated privileges user (admin) it may ask for a report dump about all the employees’ working hours (the dump is exported to the admin’s smartphone SD-card).

  3. Parser:

    A simple python script which parse the dumped report and outputs two graphs (examples below).

Problems and Solutions

We have faced several problems during the development and research phase:

  1. Board application:
    1. ExtFlash API:

      We used the ExtFlash driver API to operate with the external flash memory chip. Initially it didn’t work and we suffered from a non-deterministic behavior, sometimes the data was written and sometime not, in other times we found ourselves in a dead-lock. Surprisingly, after reinstalling the all setup (TI-RTOS, CCS and Simple Academy) the weird behavior vanished.

    2. External Flash Memory Chip:

      Misunderstanding of the chip hardware. After reading the TRM we figured out how to work with it and we changed our data structures to fit with the hardware (We separated metadata which needs to be rewritten over and over again from the records which are appendable data.

    3. Stack Size:

      The board application has grown big and the large amount of static variables, local variables and functions call depths has reached stack size and caused our application to abort. We refactored our functions and increased the stack size a little bit.

  2. Android application:
    1. Permissions Mechanism in Android 6:

      Since android 6, the operating system requires run time permissions for using Bluetooth in applications, without requesting it explicitly the permission will not be given.

    2. BLE Protocol:

      We had to add an additional layer over the BLE protocol to make it synchronic instead of a-synchronic for immediate communication and data transfers.

  3. General:
    1. Debugging:

      Hard simultaneous debugging of the board application and the android application: We used a third-party application (BLE Scanner) which we assumed works fine. When we had a bug and we weren’t sure if it’s in the board application or the android application we would test it with the external application (If it worked, we knew that the bug was in the android application, otherwise in the board application).

    2. Documentation:

      Both of the examples (project zero and BluetoothLeGatt) have minimal documentation and we had to read a lot of code and look on many examples until we managed to write our own modules.

BLE MITM

Our original project was BLE MITM in which we wanted to simulate an MITM attack using the CC2650-LAUNCHXL.

Unfortunately we didn't manage to complete the project and stopped in the research phase after attacking the first goal from several directions (be able to use the board as BLE sniffer).

Research Road

  1. SimpleBLEObserver:

    We found open source project: SimpleBLEObserver (can be found in BLE Stack extended examples). The project enables BLE advertisements sniffing but it was designed and programmed for CC2650DK. After consulting for help in TI forums, we were told that in order to port it to CC2650LP we must change parts of the code. We refactor many portions of the code, mainly compilation constants, buttons, UART vs LCD and more. Finally we found ported SimpleBLEObserver project in github for our board. Bottom line: we managed to sniff BLE advertisements.

  2. Extending SimpleBLEObserver:

    Next goal was extending the project to allow sniff any BLE packet (known as promiscuous mode) we tried to work in different layers of the BLE-Stack in order to accomplish this goal. We found it very difficult and we abandoned this approach.

  3. RF Driver:

    We tried using the RF driver in order to sniff any BLE packets and we even tried to understand how BLE stack uses this driver without any progress.

  4. Contiki OS:

    At last we turned to another operating system - contiki, which has a sniffer project (sensniff). We succeeded compiling and flashing the binary on the board and even configured CCS to debug the project with the sources, but although the project ran it didn't sniff any packets at all.